【レポート】AWS Summit Tokyo 2017: [集英社] 読書アプリクイックスタートガイド：AWSを活用したアプリ事業開発事例とデジタルコミックス制作フロー #AWSSummit

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは、導入事例トラック 3のセッション、「 [集英社] 読書アプリクイックスタートガイド：AWSを活用したアプリ事業開発事例とデジタルコミックス制作フロー」をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

発表者

• 大村 嘉範
• デジタル事業部 所属
  • 集英社は漫画、文字、雑誌がメイン
  • 当初はコンテンツのオフィシャルサイトの管理
  • 前者2つに関する電子書籍、読書アプリ
• 技術カテゴリーを担当
  • データ分析
  • AWSの構築/運用

スマホ端末からのコンテンツ体験

• コミック・雑誌・書籍がスマホで読まれることが多くなった
• 1,2ヶ月に1つぐらいのペースで自社アプリを立ち上げ

ウェブとアプリの違い

書籍アプリはウェブに比べて

• 表現が柔軟
• 購買処理の介入が柔軟
  • 定期購読
  • 話販売
  • 体力課金
  • レンタルモデル
• 新たな読者を生み出し、素晴らしい作品を生み出す土壌になっている
• プッシュ通知
  • 読者のエンゲージメントを高める

読書アプリについて

• マーケットプレイスが細分化
• アニメのオンデマンド配信
• 出版事業としては逆風
• クロスメディア戦略には活用し易い

多くの自社サービスを運営し、横串で、総合的に読者にインセンティブを与えることが大事と考えている

読書アプリ

• 開発手法・プラットフォーム・ライブラリーと電子書籍事業は成熟しつつある
• 集英社のサービスはライトウェイトなもの

今回の発表について

• 最近ローンチした幾つかの事業の事例を紹介
  • 出版社の方は自社アプリを作れるように
  • ディベロッパーの方はプラットフォームの整備・参入につながるように

マイジャンプの紹介

• 2016/8/8 サービススタート
• あなただけのジャンプを創刊できる
• 「話」の単位で構成できる
• 「ジャンプの編集長」になれる
• サブスクリプションモデル

マイジャンプの課題

コンテンツ管理に関する課題

• いままで「巻」の単位で管理
• デジタルのフローは複雑
• 底本からデジタルデータを作成
• 基礎情報が正しいか
• これを 「話」の単位でチェック→面倒

サービス立ち上げに伴う課題

• コミックビューアーを一から開発
• サービスの盛り上がりが読めない
• サイジングが難しい

インフラの観点から

• 本番
• ステージング → バージョンアップ時の内部公開、本番障害の検証
• 開発

環境の複製について

• AWSはスナップショット管理が簡単
  • 環境のコピーがかんたん
  • バックアップにもなる

コンテンツのデータサイズが非常に大きい

• 配信データが非常に多い
• 36TB程度ある
• いまは数時間で検証環境ができる

アプリのテスト

アプリのテストは以下を利用

• testflight
• deploygate

システムは2つある

• ユーザー系
  • 複数のコンテンツ・アプリから利用される
• コンテンツ・アプリ系

ライフサイクル、データ管理が大きく異なるのでVPCを分けている

データベース

• Amazon Auroraを利用
• マイジャンプでは、事前サイジングが難しかった。シームレスにスケールアップ可能であることが求められた
• 障害テストのシミュレーションが充実していて便利

クラウドフロント・コンテンツビューワについて

• 読者が選んだ好きな作品を週刊誌として定期購読するビジネス
• ユーザー x コンテンツ分のデータが毎週作成される
• 雑誌的なUIを実現
  • 目次からジャンプ
  • 次の話に飛ぶ

表紙を作ることも可能

• 表紙もパーソナライズ可能
• コンテンツはS3上に設置
• 暗号化・難読化されたデータを隠蔽されたURLで CloudFront 経由で配信
  • 難読化→画像をジグソーパズルのように分割してS3に設置。クライアントでピースを合体する

デジタルコミックス製作フロー

1. 書誌作成
2. EPUB作成依頼
3. EPUBをオーサリング会社から納品
4. 目次作成
5. 検品
6. ストア(Kindle, マイジャンプ)に入稿

大容量のコンテンツ

• コンテンツ作成のたびに、いろんな元データが作成される
• 元データを縮小してコンテンツデータを作成している
• ストアによって解像度も異なる
• バリエーションが多く、配信コンテンツのデータサイズが膨れ上がる
• 入稿データをとっておくのが大変

データセンターに移行プロジェクトが始まる前

ストレージ

• オンプレに80TBのNASを構築
  • 障害時の対応が面倒。
  • 保守・運用費用が膨大
• S3に移行した

底本

• 重版訂正
  • 単純な訂正
  • 時代の変化に伴う表現の変更
• 底本から複数のファイルが生成される
  • 期間限定ファイル
  • 話単位ファイル
  • 1/2 分冊ファイル
• 各ファイルで個別に重版訂正するのは現実的ではない
• デジタル底本を修正すると、派生ファイルも連動して変わるようにして対応

効率よい製作フロー

• 効率よく
  • 製作
  • 確認
  • 入稿
• する仕組みが必要
• 自社でこれらのフローを簡略化するシステムを作成
• システム上でプレビュー可能

デジタルコミック冊数

• S3を使わないとコストが嵩む
• 当初は5年で8000冊想定でオンプレを構築
• 実際は21000冊を超えている

冊数が多い理由はバリエーションの多さ

当初は予想していなかった販売形態の細分化

• 期間限定ファイル
• 話単位の配信
• キャンペーン

ストレージコストの最適化

3種類のストレージを用意

• NAS on EC2
  • 即時にアクセスが必要なコンテンツ
  • EPUBデータ
  • ソースコード
  • など
• Storage Gateway/S3
  • 業務の中でまれに必要だが頻繁なアクセスは不要なコンテンツ
  • S3をファイルシステムとして使う
• Glacier
  • 触らないが、保全のために必要なアーカイブデータ
  • S3のライフサイクル設定でGlacierに移動
  • コミックデータのPhotoshopの元データ
  • 原稿のスキャンデータな
  • Photoshopのカラーリングの元データ
  • S3のバックアップ
  • EC2のスナップショットのバックアップ

DMP環境

• 主なデータはS3経由でRedshiftに投入している
• セールスデータがいろいろなところから生成される

データの流れ

SQL Server -> S3                         -> Redshift -> Tableau Server
               `-> EC2/Pythonで加工 -> S3 -/

• Tableau Serverを通じて、売上の推移が瞬時にわかる
  • 昨日までにキングダムはどれだけ売れたのか?
  • テレビの芸人の紹介などでの売上がどのくらい変わったのか?
• Athena 移行も考えている

アプリを開発する上での課題

• 実装上のインフラの利用率がクライアント企業(集英社側)からは判断しにくい
• ベンダーロックインは避けたい
• 一つのシステムを複数社に実装してもらう
  • バージョンごとにベンダーを変えて対応
  • 発注元(集英社)は修正箇所を指示できない
  • 競合にあたるベンダー同士をうまく繋げないといけない

プロジェクト管理

システムごとの複数ベンダーの管理に利用しているサービス

• Redmine(ITS)
• subversion(VCS)
• teampass(パスワード管理)
• メールディーラーで連絡

AWS リソースの権限管理

• 複数ベンダーが同じAWSアカウントでリソース操作する
• インスタンスを起動したIAM ユーザーによって、Lambda でタグを適切に設定
• そのユーザーしかインスタンスの変更・停止をできないようにする

運用と監視

• 複数ベンダーが関わって運営 − アプリ開発とインフラ会社が別
• アプリケーションが正常に動いていることの担保・問題の切り分けを運用／監視側が行えるような工夫が必要

感想

普段は見聞きすることの少ない電子書籍の製作フローについて話が聞けて貴重でした。

ストレージシステムを複数用意し、コンテンツのアクセスパターンに応じてストレージを使い分けるアイデアは、電子書籍に限らず、サービスの運用者にとって、参考になるのではないでしょうか。